-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Support PEP420 (implicit namespace packages) as --pyargs
target.
#13426
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Previously, when running `--pyargs pkg`, if you didn't have `pkg/__init__.py`, pytest would fail with `ERROR: module or package not found: pkg (missing __init__.py?)`. Now it's discovering the package and tests inside it correctly. If used in conjunction with `consider_namespace_packages` in config, test modules get correct `__package__` and `__name__` attributes as well. Fixes: pytest-dev#478 Other relevant issues: - pytest-dev#2371 - pytest-dev#10569 In addition, remove `"namespace"` origin handling -- this value isn't used since python 3.8. See: - python/cpython#5481 - https://docs.python.org/3/library/importlib.html#importlib.machinery.ModuleSpec.submodule_search_locations
"""Dotted name and parts.""" | ||
if namespace_package: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I kind of piggybacked on the existing test that covers this functionality, but not sure whether it's a bit dirty!
Please let me know if you'd prefer me to do it in some other way, e.g. create a new fixture specifically for this case. Or perhaps this should be tested in some different place rather than test_main
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @karlicoss,
I think it is perfectly fine to reuse an existing test like this one, thanks!
However functionality related to collection and packages tends to break complex test suites in subtle ways... been there done that.
But to be honest not sure how we can even foresee how this will be handled in the wild, unless we put it in the wild.
I'm considering adding this behind a feature flag, so if it causes havoc, we can optionally revert it...
On the other hand, we can just bite the bullet and see. If this causes massive breakage, we can always revert the patch and make a hot fix.
Just thinking aloud here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the other hand, we can just bite the bullet and see. If this causes massive breakage, we can always revert the patch and make a hot fix.
No, agree, it makes a lot of sense! From experience, such random breakages are pretty annoying. Happy to implement a feature flag and add documentation for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been thinking about the flag name & documentation.. and actually, perhaps it makes sense to simply reuse consider_namespace_packages
?
From my experience with it, right now only helps with package/module names. E.g. if there is a test inside test_pkg.py
src/
pkg/
test_pkg.py
And we run PYTHONPATH=src pytest --pyargs pkg.test_pkg
It correctly discovers tests in both cases, but.
-
with
consider_namespace_packages
, it has__package == "pkg"
and__module__ == "pkg.test_pkg"
(as one might expect) -
without
consider_namespace_packages
, it has__package == ""
and__module__ == "test_pkg"
If we add
pkg/__init__.py
, this has correct__package__
and__module__
though.
This is consistent with --help
:
Consider namespace packages when resolving module names during import
However, according to https://docs.pytest.org/en/stable/reference/reference.html#confval-consider_namespace_packages
Controls if pytest should attempt to identify namespace packages when collecting Python modules. Default is False.
Set to True if the package you are testing is part of a namespace package.
So the docs say it "should attempt to idenfity when collecting", but I'm not sure what this actually means here.
E.g. if you have the following hierarchy:
src/
pkg/
__init__.py
subpkg/
test_subpkg.py
pkg
is a regular package with __init__.py
, but pkg.subpkg
is a namespace subpackage.
Then if you run PYTHONPATH=src pytest --pyargs pkg
(with upstream pytest), pytest correctly discovers the test in test_subpkg.py
The only difference is
- with
consider_namespace_packages
it correctly sets__package__
and__module__
intest_subpkg.py
- without, it sets
__package__ = ""
From a lurk in pytest code, to me it feels that indeed it has to do more with naming than test discovery -- e.g. I think stuff in this file is mostly after we already collected candidate files to run?
Line 494 in 83536b4
consider_namespace_packages: bool, |
So perhaps if I just reuse consider_namespace_packages
, this makes it closer to the original intent? So it could both discover tests under namespace packages (this PR), and they also will have correct __package__/__module__
attributes (already working in upstream pytest).
This also limits the potential impact from the change -- there are "only" 400ish matches for this setting on github https://github.com/search?q=consider_namespace_packages&type=code (tiny amount comparing to total pytest users), and I'd imagine people who use this setting know what they are doing anyway.
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for tackling such a long standing issue @karlicoss , appreciate it!
"""Dotted name and parts.""" | ||
if namespace_package: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @karlicoss,
I think it is perfectly fine to reuse an existing test like this one, thanks!
However functionality related to collection and packages tends to break complex test suites in subtle ways... been there done that.
But to be honest not sure how we can even foresee how this will be handled in the wild, unless we put it in the wild.
I'm considering adding this behind a feature flag, so if it causes havoc, we can optionally revert it...
On the other hand, we can just bite the bullet and see. If this causes massive breakage, we can always revert the patch and make a hot fix.
Just thinking aloud here.
@@ -0,0 +1 @@ | |||
Support PEP420 (implicit namespace packages) as `--pyargs` target. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add a section to the docs related to this support somewhere in the docs?
# If submodule_search_locations is set, it's a package (regular or namespace). | ||
# Typically there is a single entry, but documentation claims it can be empty too | ||
# (e.g. if the package has no physical location). | ||
return spec.submodule_search_locations[0] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps instead of just returning it blindly, we should check if this is a directory before returning?
looks lik all good, allows to get rid of horrible conftest hacks!
Previously, when running
--pyargs pkg
, if you didn't havepkg/__init__.py
, pytest would fail withERROR: module or package not found: pkg (missing __init__.py?)
.Now it's discovering the package and tests inside it correctly.
If used in conjunction with
consider_namespace_packages
in config, test modules get correct__package__
and__name__
attributes as well.Fixes: #478
Other relevant issues:
In addition, remove
"namespace"
origin handling -- this value isn't used since python 3.8. See: